Pożar na produkcji - czyli gdzie zaczyna się seniority?

Chyba każdy, kto pracował przy tworzeniu oprogramowania, zna ten scenariusz. Dzień deploymentu, wdrożenie się powiodło, pipeline świeci na zielono, a długo wyczekiwany feature jest już na produkcji. Zespół świętuje, biznes cieszy się, że nowa funkcjonalność ułatwi pracę… aż nagle okazuje się, że zaczynają sypać się błędy. Flow nie działa tak, jak powinien, dane aktualizują się w nieoczekiwany sposób albo błąd całkowicie uniemożliwia tworzenie nowych rekordów. Stawka robi się jeszcze większa, gdy problem oznacza realne straty finansowe lub ryzyko utraty reputacji firmy. Pierwszy odruch? “Trzeba to jak najszybciej naprawić!”. Ale uwaga - właśnie wtedy można popełnić błąd znacznie poważniejszy niż ten, który wywołał cały problem!

Sam kryzys na produkcji nie jest jeszcze najgorszym scenariuszem. Błędy się zdarzają i nie da się ich całkowicie wyeliminować. Znacznie groźniejsza może okazać się chaotyczna reakcja na nie.

Nie taki senior nieomylny, jak go malują

Wśród wielu osób - szczególnie midów i juniorów - panuje przekonanie, że osoba mianowana seniorem jest odporna na błędy. To mit. Bo owszem - senior może dobrze znać platformę, pisać dobre testy, robić lepsze code review, znać procedury deploymentu oraz ryzyka wprowadzanych zmian. Żadna z tych rzeczy nie daje jednak nieomylności.

Wraz z doświadczeniem często rośnie też zakres odpowiedzialności. Bardziej skomplikowane procesy, więcej zależności, wsparcie młodszych kolegów, spotkania i “szybkie calle” dokładają kolejne elementy, o których trzeba pamiętać. A im bardziej złożony system i większe obciążenie poznawcze, tym więcej okazji do przeoczenia czegoś mimo stosowania dobrych praktyk. Do tego praca z Salesforce to nieustanna nauka. Możesz być w ekosystemie 5, 10 czy 20 lat i nadal nie wiedzieć wszystkiego.

Doświadczenie nie sprawia, że człowiek przestaje popełniać błędy. Senior tym różni się od mida czy juniora, że lepiej zarządza ich ryzykiem i konsekwencjami. I właśnie w sytuacji kryzysowej tę różnicę widać szczególnie dobrze.

Zanim wyciągniesz plastry i trytytki… najpierw oceń, co się zepsuło

Pierwszym odruchem mniej doświadczonej osoby może być otwarcie VS Code lub Setupu i rozpoczęcie poszukiwania poprawki. Senior wie jednak, że zanim zacznie cokolwiek naprawiać, musi zatrzymać się i ocenić sytuację.

Co dokładnie nie działa i od kiedy? Czy to na pewno nasz deploy coś zepsuł, czy może problem siedział na produkcji już wcześniej? Jaka jest jego skala i kogo dotyczy? Service Agentów, którzy nie mogą wykonywać swojej pracy? A może klientów, którzy nie mogą sfinalizować zakupu?

Senior sprawdza też, jakie procesy zostały dotknięte i czy problem wpływa na kolejne. Czy zagrożone są dane? Co się stanie, jeśli przez następne 30 minut niczego nie zrobimy? Czy istnieje workaround?

Nie zakłada również, że każde zgłoszenie oznacza bug. Źródłem problemu może być bałagan w danych albo niewłaściwe korzystanie z systemu. Nawet “user error” nie zawsze zamyka temat - warto sprawdzić, czy użytkownik dostał odpowiednią dokumentację i szkolenie.

Junior szuka więc odpowiedzi na pytanie: “Jak to naprawić?”. Senior najpierw chce wiedzieć: “Co właściwie się stało i jakie są tego konsekwencje?”. Jednocześnie pamięta, że komunikacja jest częścią rozwiązania. Jasno oddziela to, co już wie, od tego, czego jeszcze nie wie. Unika spekulacji przedstawianych jako fakty, technicznego żargonu i obiecywania terminu naprawy bez podstaw. Przede wszystkim nie zostawia biznesu w ciszy, kiedy sam nadal szuka odpowiedzi.

Dobrymi chęciami bug wybrukowany… czyli jak nie narobić szkód “naprawiając”

Mamy ustalone, co się zepsuło i jaki proces na tym cierpi. Widzimy też, że technicznie da się to naprawić w prosty sposób - jednym kliknięciem w Setupie. Junior już się cieszy: jeden klik i po krzyku! Senior zadaje jeszcze jedno pytanie: co jeszcze się stanie, kiedy klikniemy?

Bo “prosta technicznie” poprawka może mieć już nie tak proste konsekwencje dla innych procesów czy bezpieczeństwa danych. Senior nie patrzy więc wyłącznie na konfigurację, która stoi mu na drodze. Sprawdza, dlaczego istnieje na produkcji, od czego zależy i co jeszcze może korzystać z jej obecnego ustawienia. Jej wyłączenie może ugasić jeden pożar i jednocześnie rozpalić drugi.

Mniej doświadczona osoba często koncentruje się na pierwszym rozwiązaniu, które działa. Senior szuka alternatyw - nawet jeśli wymagają większego nakładu pracy. Sprawdza możliwość rollbacku, rozważa hotfix czy workaround i porównuje ich wpływ na procesy, dane i użytkowników. Najprostsze rozwiązanie nie zawsze jest tym najbezpieczniejszym.

Różnicę widać również wtedy, kiedy trzeba przedstawić warianty biznesowi. Junior może powiedzieć: “Mamy trzy opcje. Którą wybieracie?”. Senior wie, że sama lista możliwości to za mało. Biznes musi znać wpływ każdej opcji na swoje procesy, natomiast specjalista powinien ocenić konsekwencje techniczne i ryzyko, a następnie przedstawić rekomendację: “Mamy trzy możliwości. Rekomenduję wariant B, ponieważ…”.

Nie oznacza to zasypywania biznesu technicznymi szczegółami. Senior powinien potrafić przełożyć je na język ryzyka i wpływu na procesy. Ostateczna decyzja może należeć do biznesu - zadaniem specjalisty jest sprawić, żeby była świadoma.

Ownership bez polowania na czarownice

Kolejną z istotnych różnic między juniorem a seniorem jest umiejętność przyznania się do błędu lub niewiedzy bez umniejszania własnej wartości. Mniej doświadczonej osobie może towarzyszyć przekonanie, że przyznanie się do spowodowania pożaru podważy jej wiedzę lub kompetencje. W efekcie pojawia się pokusa, żeby problem przemilczeć, umniejszyć albo spróbować naprawić po cichu.

Dlatego tak ważna jest postawa seniora. Jeśli sam popełnił błąd - mówi o tym otwarcie i skupia się na jego rozwiązaniu. Jeśli zawinił ktoś inny, szczególnie osoba z mniejszym doświadczeniem, jego celem nie powinno być znalezienie kozła ofiarnego, ale zrozumienie, co się wydarzyło i dlaczego. Senior buduje w ten sposób przestrzeń, w której można powiedzieć “to moja zmiana spowodowała problem” bez obawy przed publicznym szukaniem winnego.

Nie chodzi przy tym wyłącznie o koleżeńską atmosferę. Trudno szybko ugasić pożar, jeśli część zespołu boi się powiedzieć, skąd właściwie pojawił się ogień. Strach przed przyznaniem się do błędu utrudnia przepływ informacji, opóźnia reakcję i sprawia, że trudniej później zabezpieczyć proces przed powtórką. Ownership oznacza więc wzięcie odpowiedzialności za błąd - nie rozpoczęcie polowania na czarownice.

Mądry developer po szkodzie - czyli o jeden wniosek bliżej do seniority

Dobra wiadomość jest taka - każdy pożar na produkcji dodaje +100 punktów doświadczenia całemu zespołowi. Juniorzy i midzi mają szansę nauczyć się od starszych koleżanek i kolegów zarządzania sytuacją kryzysową. Seniorzy - ulepszania procesów zarządzania zmianami.

Praca nad błędem nie kończy się jednak na fixie. Po opanowaniu sytuacji zespół powinien przeanalizować incydent i odpowiedzieć na kilka pytań. Dlaczego testy nie wykryły błędu? Czy scenariusz biznesowy został dobrze rozpisany? Czy istnieje rozbieżność między środowiskami, której nie przewidzieliśmy? Czy ktoś miał szansę zauważyć problem wcześniej? To powinien być początek analizy, ale nie jej koniec.

Analiza powinna prowadzić do zmiany dotychczasowego sposobu pracy. W przeciwnym razie mamy do czynienia ze zmarnowaną lekcją. Jej efektem może być dodatkowy test, sanity check, zmiana procesu review, usprawniony monitoring czy lepszy rollback plan. Nie chodzi o dokładanie procedur dla samych procedur, ale o to, żeby ten sam pożar było trudniej wywołać po raz drugi.

Bo seniority nie bierze się wyłącznie z lat spędzonych w ekosystemie czy liczby poznanych funkcjonalności. Budują je również takie doświadczenia - pod warunkiem, że po ugaszeniu pożaru zostanie po nich coś więcej niż zamknięty ticket.

O autorce

Sandra Kuc-Malinowska - Salesforce Developer, zajmująca się rozwojem i utrzymaniem rozwiązań opartych na platformie Salesforce. W swojej pracy łączy programowanie z automatyzacją procesów, integracjami oraz analizą wymagań biznesowych. Szczególnie interesuje ją projektowanie rozwiązań, w których technologia odpowiada na realne potrzeby i procesy biznesowe.